All the Perl that's Practical to Extract and Report

Productizing Software and Open Source

Mark Leighton Fisher on 2003-05-30T21:05:51

Sometimes it is just too much bother to productize software you have written (i.e. turn the software into a marketable product). As an example, Micro Data Base Systems in the early 1980's needed a better office file transfer system than sneakernet, so Tim Stockman wrote a program for file transfers over serial lines that was significantly better than the XMODEM etc. programs available at the time (making our file transfers through the central serial line switchbox very convenient for that time). However, serial line file transfer programs were far away from the MDBS stock-in-trade of PC databases, so the program stayed in-house. This is one example of where making a program Open Source would have benefited the whole software community including the original author's company.

Turning software that is already written into a product requires a whole host of activities, ranging from market studies to graphical package design to CD reproduction. These activities are not needed for Open Source software. The only added step needed after the Open Source software is tested, working, and documented is to place the software out on a reliable repository.

Most software is written for in-house use, irrespective of whether other entities could make use of that software. IMHO, making such software Open Source when:

  • There is no clear competitive advantage to keeping the software in-house (a counter-example could be automatic stock-trading software at a brokerage, as this would embody trade secrets of the brokerage); and
  • The software has some general utility rather than being specific to the company in question;

makes a lot of sense to me. Most businesses are not in the retail software market (RCA (consumer electronics), Eli Lilly (pharmaceuticals), Tyson (chicken), etc.). But metric boatloads of software is written by these companies, much of which does not contain any trade secrets but is generally useful. This software could be made Open Source, thereby providing additional developers/testers/documenters to the entity without costing the entity more than the time required to make the software suitable for Open Source distribution. Although time is required to process in-house software into a form suitable for Open Source distribution, this could be paid back by the efforts of those outside the entity who are using the software and improving it, reporting defects, etc. I have yet to see an in-house software development department that has enough staff to implement every requested improvement.

The process of turning existing in-house software into Open Source software has the advantage that the software will already be written, documented (some), and working, whereas many current Open Source projects do not have enough resources to get to the point where they have written and working software even when the software is not documented.

Most software was never destined for the retail shelf, but has clear general utility without giving significant competitive advantage to the entity that created the software. If that software was made Open Source, (again IMHO) there would be benefits to both the original authoring entity and the software community as a whole.

That is...

james on 2003-05-31T10:50:30

...the essence of the principle we apply at Fotango. While we do hold code that we would not release, there large majority of code we produce is open sourced for at least the reasons you presented.

At the very heart of economics of this, the software is often a loss-leader. We must produce the software in order to accomplish our business objectives. However, the software itself has no value other than the time that was spent writing it. Companies do recognize this, which is why the IT function of a company often reports to the CFO.

The false economy that an awful lot of people place on software is the belief that it either a) it can be monetized to recover the development cost, or b) that the software gives them a business advantage.

The truth surrounding belief 'a' is that the ability to recover the cost of developing software through software sales is the rare case rather than the common case. Belief 'b' has more ground in truth, but really the important thing for companies to recognize is that the software itself is not providing a competetive advantage, but rather the data that it processes or provides is.